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Software  Process  Development  and  Enactment: 
Concepts  and  Definitions 


Abstract:  The  scientific  treatment  of  the  software  process  is  relatively  new 
and,  as  with  any  new  field,  the  initial  terminology  is  often  confusing.  When 
terms  can  have  a  diversity  of  meanings,  technical  communication  is  more 
difficult  and  technological  progress  is  constrained.  This  paper  defines  a  core 
set  of  concepts  about  the  software  process.  These  concepts  are  intended  to 
facilitate  communications  and  to  provide  a  framework  for  further  definitions. 
The  definitions  focus  on  essential  concepts;  however,  they  do  not  represent  a 
comprehensive  glossary  of  common  software  process  terms.  Following  an 
initial  overview,  this  paper  outlines  the  basic  process  concepts  which  underlie 
the  definitions.  The  definitions  are  then  grouped  in  four  sets:  a  framework  for 
process  definition,  an  engineering  of  process,  an  enactment  of  process,  and 
process  properties.  This  is  followed  by  illustrations  of  ihe  use  of  these  concepts 
in  several  domains.  The  paper  concludes  with  some  observations  on  the 
definition  process. 


1  Overview 

This  report  includes  descriptions  of  some  basic  “core"  software  process  terms.  Its  purpose  is 
to  provide  a  common  communication  framework  for  the  software  process  and  to  reflect  the 
views  and  findings  of  leading  software  process  researchers.  With  the  growing  scientific  focus 
on  the  software  process,  there  is  a  need  for  common  terms  and  definitions.  It  is  hoped  that  this 
paper  will  facilitate  communication  and  foster  continued  development  of  software  process 
technology.  It  is  also  hoped  that  this  basic  definition  set  will  serve  as  a  foundation  for  further 
definitions  and  ultimately  a  comprehensive  glossary  of  software  process  terminology. 

This  effort  was  initiated  at  the  6th  International  Software  Process  Workshop  (ISPW6).  Several 
workshop  participants  noted  the  need  for  a  document  to  describe  and  define  the  terms  com¬ 
monly  used  by  the  software  process  community.  A  small  group  headed  by  Peter  Feiler  and 
Watts  Humphrey  volunteered  to  develop  these  definitions.  The  plan  was  to  focus  on  a  core  set 
of  approximately  25  to  30  terms  that  covered  the  basic  set  of  process  concepts.  With  input 
from  many  sources,  the  authors  have  established  a  core  set  of  definitions  and  documented 
them  in  this  report.  To  limit  the  number  of  terms,  terms  whose  definitions  can  be  easily  mapped 
to  the  abstract  concepts  defined  here  have  been  omitted.  To  constrain  the  scope  of  this  work, 
many  terms  with  applicable  existing  definitions  have  also  been  omitted.  Thus,  this  document 
does  not  represent  a  comprehensive  glossary  of  terms  in  the  software  process  domain. 

An  appreciation  of  the  importance  of  definitions  can  be  seen  from  the  work  of  Simon  and  oth¬ 
ers.  They  have  shown  that  people  retain  information  in  chunks  [Simon  81].  People  typically 
think  of  these  chunks  as  units,  and  they  have  widely  varying  chunk  "vocabularies"  with  which 
they  are  fluent.  There  is  also  evidence  that  expert  knowledge  is  built  by  the  accumulation  of 
an  expanding  store  of  such  "chunks."  It  would  thus  appear  that  one's  ability  to  think  and  to 
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communicate  can  be  substantially  enhanced  with  a  precisely  defined  set  of  rich  abstractions. 
As  a  broad  community  of  professionals  arrives  at  a  common  understanding  of  terms  to  de¬ 
scribe  common  abstractions,  it  is  better  able  to  communicate  succinctly  and  precisely.  In  ad¬ 
vanced  technical  work,  communication  permits  now  work  to  be  built  on  prior  achievements. 
Improved  communication  thus  facilitates  more  rapid  technological  advancement  and  more 
rapid  application  of  that  technology  to  the  betterment  of  humankind. 

Process  concepts  are  being  applied  to  software  with  increasing  success  ([Humphrey  91], 
(Kolkhorst  88])  but  the  rate  of  application  of  these  concepts  is  limited  both  by  the  relatively 
primitive  State  of  knowiedgo  in  this  new  field  and  by  the  lack  of  a  common  and  precise  basis 
for  technical  communication.  The  first  requirement  for  precise  communication  is  an  agreed- 
upon  core  of  terminology.  Without  such  agreement,  people  are  less  able  to  understand  others’ 
work  and  to  build  upon  it.  As  software  evolves  from  a  craft  to  an  engineering  discipline,  tech¬ 
nical  advances  must  draw  on  a  broader  context  than  can  be  reached  through  personal  expe¬ 
rience.  The  basic  reason  for  this  report  is  to  propose  an  initial  foundation  for  communication 
on  software  process. 

Section  2  of  this  paper  provides  the  conceptual  context  for  the  definiti'^ns,  followed,  in  Section 
3,  by  the  software  process  definitions.  Many  of  the  term?  ure  accompanied  by  explanatory 
comments.  Section  4  illustrates  the  use  of  these  abstract  concept  definitions  to  describe  some 
common  process  terms.  Section  5  contains  a  brief  summ.iry  of  the  authors'  views  on  the  state 
of  p.'occss  technology  and  what  can  be  expected  in  the  future. 


2 


CMU  .$f:i-92-Tn-4 


2  The  Software  Process  Context 


The  meanings  of  terms  are  often  dependent  on  the  contexts  in  which  they  are  used.  The  def¬ 
initions  in  this  paper  were  developed  within  the  context  of  the  authors’  views  and  opinions  on 
the  software  process.  Pather  than  require  the  reader  to  infer  the  context  for  these  definitions, 
the  paper  starts  with  a  brief  discussion  of  this  context,  it  is  the  authors'  view,  however,  that  as 
other  fields  apply  process  principles,  many  of  these  definitions  will  be  found  applicable. 

A  definition  framework  has  been  found  to  be  useful  for  thinking  about  the  software  process 
and  the  most  critical  terms  needed  to  define  and  discuss  it.  It  has  helped  to  detect  gaps  and 
has  clarified  the  relationships  of  the  various  terms.  The  selected  structure  is  shown  in  Figure 
2-1 ,  which  identifies  the  overall  relationships  among  software  and  process  activities  and  indi¬ 
cates  the  activities  to  which  the  various  definitions  relate.  This  overall  structure  has  been  help¬ 
ful  in  this  definition  work  and  it  may  also  be  useful  to  the  reader. 

Process  Framework 
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Engineering 
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Figure  2-1  Structure  of  Process  Concepts 
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Another  context  question  concerns  the  scr,..r:  o,  p:  jces  j  issues  to  be  covered.  While  there  is 
considerable  interest  and  activity  on  the  -:jje  ,(s  of  process  management  and  process 

improvement,  the  scope  of  these  definil  ;ia?  .een  limited  intentionally  to  definition,  mod¬ 
eling,  and  enactment  issues.  This  does  not  imply  that  the  broader  management  issues  are  not 
important,  but  that  their  inclusion  would  extend  the  scope  of  this  work  far  beyond  the  authors’ 
original  intent.  There  is  a\'  \  cro  'ing  literature  on  process  management  topics  that  provides 

at  least  some  definitional  ^  ce  ([Humphrey  89],  [Paulk  91]). 

Finally,  there  is  no  simple  way  to  limit  the  scope  of  a  definition  document.  In  a  subject  as  new 
as  the  software  process,  many  ordinary  terms  can  have  subtle  meanings.  The  selection  of 
terms  to  include  in  these  definitions  was  thus  based  on  two  criteria;  the  term  represents  an 
essential  process  concept  that  cannot  easily  be  derived  from  other  concepts,  or  the  term  is 
currently  being  used  inconsistently.  As  a  result,  terms  such  as  model,  definition,  and  fidelity 
have  been  included  while  subprocess,  template,  or  cue  have  not. 

2.1  A  Framework  for  Process  Definition 

Software  development  organizations  have  found  that  by  defining  their  processes  they  improve 
their  effectiveness  ([Humphrey  91],  [Kolkhorst  88]).  To  the  extent  that  software  process  defi¬ 
nitions^  make  high-quality  software  easier  and  more  economical  to  produce,  they  will  become 
widely  valued  and  used.  This  means  that  software  process  definitions  must  be  both  useful  to 
the  practitioners  and  reasonably  economical  to  produce.  Experience  to  date,  however,  dem¬ 
onstrates  that  the  development  of  a  comprehensive  software  process  definition  can  be  very 
expensive  and  time  consuming.  Thus,  there  is  a  premium  on  widely  applicable  means  for  de¬ 
veloping  general  purpose  process  aeimitions  togeiner  with  techniques  lOi  reusing,  tailoring, 
and  enhancing  them.  Just  as  with  software,  this  implies  that  large  scale  software  processes 
should  be  carefully  designed  and  constructed. 

Tlie  concept  of  a  softv.'are  process  architecture  can  be  best  described  by  examining  how  or¬ 
ganizations  a''e  likely  to  use  process  definitions.  Rather  than  having  a  single  mcnoiithic  pro 
cess  that  all  projects  must  use.  they  will  likely  find  that  different  projects  will  have  differing 
needs.  For  example,  the  development  project  for  enhancing  a  large,  widely-used  product  will 
likely  require  some  different  process  activities  from  a  project  to  develop  a  new  program  for  a 
single  user.  Since  process  development  is  expensive,  there  is  considerable  motivation  for  pro¬ 
cess  commonality  and  sharing.  This  is  enhanced  by  the  fact  that  different  projects  in  the  same 
organization  will  likely  have  many  common  activitie;'.  Large  organizations  will  have  many  pro¬ 
cess  definitions  that  they  wish  to  share.  The  more  logical  and  explicit  the  relationship  among 
these  definitions,  the  more  likely  it  is  that  elements  of  the  various  project  processes  can  be 
shared. 


'The  reader  should  note  a  potential  confusion  with  terminology  This  paper  Is  about  the  definition  of  process  terms. 
One  such  term,  as  used  in  this  paragraph,  is  "process  definition."  which  is  la!*r  as  an  implementat.on  of 

a  process  design  in  the  form  of  a  parfiaily  ordered  set  of  process  steps  that  is  enactab.e. 
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One  way  to  address  the  need  to  share  process  definitions  is  to  develop  a  set  of  general  pur¬ 
pose.  reusable  process  elements.  Generality,  however,  requires  interfaces  and  structural 
standards:  a  complete  set  of  such  interfaces  and  standards  comprises  a  process  architecture, 
A  properly  conceived  process  architecture  should  permit  its  member  process  elements  to  be 
more  widely  used  and  thus  to  be  more  economically  viable. 

Another  question  concerns  the  degree  of  process  refinement.  A  complex  software  process 
can  be  viewed  as  a  nested  set  of  abstractions.  Each  process  is  composed  of  subprocesses, 
each  of  which  in  turn  may  also  have  smaller  elements.  While  there  is  no  clear  technical  limit 
to  the  level  of  refinement  for  a  software  process,  there  are  practical  concerns,  including  the 
scale  of  the  projects  for  which  the  process  is  designed,  the  degree  to  which  the  work  is  parti¬ 
tioned  among  implementors,  the  resources  and  time  available  for  process  definition,  the  level 
of  capability  or  understanding  of  the  process  users,  and  the  scalability  of  the  process  itself. 

2.2  Engineering  of  Processes 

The  software  process  can  be  viewed  in  much  the  same  way  as  software.  It  has  many  of  the 
same  artifacts  and  requires  quite  similar  disciplines  and  methods  [Osterweil  87).  It  is  useful  to 
think  about  the  software  process  development  life  cycle  in  software  development  terms.  For 
example,  one  should  start  with  clear  requirements  followed  (or,  more  properly,  accompanied) 
by  architecture  and  design.  Processes  must  be  validated  against  users'  needs,  and  limited 
prototypes  may  be  needed  before  full  scale  development  is  undertaken.  Special  testing  is  re¬ 
quired,  as  is  planning,  instantiation,  migration  from  the  prior  process,  and  operational  support. 

Regardless  of  the  degree  of  testing,  all  process  bugs  are  not  generally  found  before  general 
process  instantiation  and  enactment.  Because  software  processes  typically  require  at  least 
partial  human  enactment,  there  is  a  major  requirement  and  usability  problem  and  it  is  much 
more  difficult  to  do  effective  testing  without  end-user  involvement.  It  is  likely  that  only  a  small 
fraction  of  the  total  number  of  process  "bugs”  will  be  found  in  early  laboratory  testing.  It  is  thus 
advisable  to  follow  process  development  testing  with  early  user  prototype  testing.  Even  then, 
as  the  projects  evolve  and  the  software  professionals  gain  experience  with  the  process,  there 
will  be  many  ideas  for  further  improvement.  It  is  thus  important  for  organizations  to  establish 
mechanisms  to  obtain  continual  user  feedback  to  guide  process  repair  and  evolution. 

The  software  development  community  is  still  learning  that  timely  and  comprehensive  user 
feedback  is  crucial  to  a  quality  development  process.  In  developing  the  software  process,  it 
takes  considerable  experience  before  process  designers  can  produce  processes  that  are  di¬ 
rectly  usable  without  major  modification  and  evolutionary  improvement.  Process  usability  is  a 
function  of  process  design,  user  experience,  the  project  domain,  ana  many  other  factors.  Be¬ 
cause  user  needs  vary  widely  even  within  a  single  organization,  and  because  the  needs  of 
each  user  will  change  with  experience,  they  must  be  thoroughly  and  regularly  monitored.  Di¬ 
rect,  continuous,  and  comprehensive  user  involvement  is  thus  essential  for  effective  process 
development  and  evolution.  Such  involvement  will  generate  improvement  suggestions  that 
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must  be  handled.  This  in  turn  will  require  process  support  facilities  for  tracking,  recording,  han¬ 
dling,  and  installing  process  fixes  and  enhancements. 

2.3  Enactment  of  Processes 

It  is  desirable  to  define  software  processes  with  sufficient  precision  so  that  many  of  the  routine 
enactment  tasks  can  be  automated.  Software  engineering  remains  a  highly  creative  process, 
and  for  the  foreseeable  future,  the  op,Dortunities  for  process  automation  will  likely  be  limited  to 
the  most  routine  activities  and  tasks.  As  a  consequence,  software  process  enactment  issues 
must  consider  human  agents  as  well  as  automation  through  machine  agents.  The  use  of  hu¬ 
man  agents  raises  issues  of  planning,  controlling,  monitoring,  enforcing,  and  training.  The 
software  process  must  also  be  monitored,  measured,  and  repaired  and  it  must  relate  to  other 
processes  and  activities  within  the  organization.  There  are  even  questions  of  unauthorized  in¬ 
trusion,  improper  process  modification,  and  process  recovery. 

In  short,  processes  have  the  full  range  of  enactment  properties  seen  with  data  processing  sys¬ 
tems.  At  one  extreme  are  small,  largely  autonomous,  single  string  processes:  at  the  other  are 
highly  structured  networks  of  interacting  parallel  processes.  The  issues  of  designing,  planning, 
monitoring,  and  controlling  must  also  vary  considerably  across  this  spectrum. 

2.4  Process  Properties 

Software  processes  must  be  evaluated.  What  constitutes  a  good  process  and  how  can  one 
tell  if  a  particular  process  fits  a  specific  user  need?  The  first  basic  requirement  is  that  the  prop¬ 
erties  of  a  specific  process  should  fit  the  needs  of  the  project  using  them.  While  a  comprehen¬ 
sive  discussion  of  process  assessment  and  evaluation  is  beyond  the  scope  of  this  paper,  there 
is  a  growing  body  of  literature  on  these  subjects.  Software  process  assessments  have  been 
widely  used  by  U.S.  software  organizations  for  several  years  [Humphrey  89]  and  there  are 
now  a  number  of  organizations  that  conduct  such  assessments  as  a  business.  The  U.S.  De¬ 
partment  of  Defense  has  also  adopted  an  SEI-developed  capability  evaluation  method  for  de¬ 
termining  the  most  effective  software  contractors  from  among  several  offerers.  The  SEI  is  also 
developing  a  Capability  Maturity  Model  which  is  a  comprehensive  listing  of  those  practices  that 
are  appropriate  for  various  levels  of  software  process  capability  [Paulk  91]. 

The  current  state  of  software  process  technology  is  such  that  process  evaluation  is  currently 
limited  to  a  rudimentary  examination  of  the  presence  or  absence  of  various  activities.  As  this 
field  evolves,  more  comprehensive  evaluations  will  be  practical.  Such  evaluations  will  likely 
examine  the  process  structure,  its  behavior  under  various  conditions,  and  its  adaptability.  At 
this  time,  it  is  premature  to  attempt  quantitative  measures  of  process  quality.  However,  there 
are  several  available  qualitative  measures.  These  relate  to  how  difficult  the  process  is  to  use 
and  the  quality  of  the  results  it  produces.  Other  properties  concern  the  degree  to  which  the 
process  has  persistence  or  whether  it  merely  executes  short  tasks  in  response  to  an  external 
agent. 
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3  Software  Process  Definitions 


This  chapter  presents  the  selected  "core"  process  terms  together  with  their  definitions  and  ex¬ 
planatory  comments.  The  definitions  are  formatted  as  follows:  the  term  being  defined  is  in 
boldface,  the  definition  for  the  term  is  in  italics,  and  any  rationale  or  explanatory  information 
is  in  plain  text  following  the  definition.  Unless  othenwise  noted,  these  terms  are  all  defined  in 
the  context  of  the  software  process.  However,  since  we  have  attempted  to  abstract  the  terms 
from  the  particular  domain  of  software  process,  they  may  have  broader  applicability.  Where 
this  is  confusing,  it  is  suggested  that  the  reader  add  the  word  "process”  before  any  term.  For 
example,  "development"  equates  to  "process  development." 

The  first  definition  is  the  term  process,  which  is  defined  at  a  highly  abstract  level.  It  is  followed 
by  two  terms  that  refer  to  pieces  of  a  process. 

Process:  A  set  of  partially  ordered  steps  intended  to  reach  a  goal.  While  the 
term  process  is  used  in  many  different  contexts,  the  context  for  this  definilion 
is  software.  For  software  development,  the  goal  is  production  or 
enhancement  of  software  products,  or  the  provision  of  services.  Other 
examples  are  the  software  maintenance  process,  the  acceptance  testing 
process,  or  the  process  development  process. 

Process  Step:  An  atomic  action  of  a  process  that  has  no  externally  visible 
substructure.  The  process  step  is  the  basic  process  abstraction.  A  process 
step  is  a  discrete,  bounded  activity  of  finite  duration  with  a  level  of  abstraction 
that  depends  on  the  enacting  context.  For  example,  a  process  step,  as  used 
by  a  programmer  and  included  in  a  process  script,  would  generally  require 
substantial  elaboration  to  be  suitable  for  a  process  program. 

Process  Element:  A  component  of  a  process.  Process  elements  range  from 
individual  process  steps  to  very  large  parts  of  processes.  They  may  be 
templates  to  be  filled  in,  fragments  to  be  completed,  or  abstractions  to  be 
refined. 

Process  Script:  A  process  definition  that  is  suitably  designed  and 
instantiated  for  enactment  by  a  human.  Process  scripts  are  designed  to  adapt 
to  the  particular  user's  needs  and  often  must  be  modified  as  users  gain 
experience  and  facility. 

Process  Program:  A  process  definition  that  is  suitably  designed  and 
instantiated  for  enactment  by  machine.  Process  programs  must  be  designed 
to  fit  the  particular  computing  environmental  needs  for  format  and  detail  and 
generally  be  tested,  debugged,  and  modified  much  like  computer  programs. 

The  remainder  of  the  definitions  are  organized  into  several  groups.  First,  the  Framework  for 
Process  Definition  defines  foundation  terms  ihat  are  used  in  the  subsequent  definitions.  Next, 
the  terms  in  Engineering  of  Process  elaborate  on  the  process  of  developing  process  defini¬ 
tions.  Concepts  concerning  the  enactment  and  management  of  defined  processes  are  de¬ 
scribed  in  Enactment  of  Processes.  Finally,  terms  defining  properties  of  defined  processes  are 
discussed  in  Process  Properties. 
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Figure  3-1  illustrates  the  relationship  among  many  of  the  process  entities  and  tne  actions  on  them.  Here, 
tne  boxes  represent  various  process  elements  and  the  arrows  refer  to  actions.  Starting,  for  example,  with 
an  initial  process  arcnitecture,  a  process  design  is  developed.  From  there,  one  or  more  process  definitions 
c.ar;  be  developed.  This  design  and  development  acti .  .ty  may  uncover  architectural  defects  or  desirable 
enhancements  that  are  fed  back  to  evolve  the  process  architecture.  Further,  existing  process  architec¬ 
tures,  designs,  and  definitions  may  be  tailored  to  fit  ce.anging  project  needs.  With  a  complete  process  def¬ 
inition.  a  plan  is  developed  for  its  pioject  use.  Th:.e  involves  analysis  and  adjustment  through  a  control 
P'oeess  and  generally  involves  external  constraints.  An  effective  control  process  will  also  utilize  measure- 
ments  through  process  traces.  Once  an  appropriate  plan  is  established,  the  process  definition  is  convert¬ 
ed  to  enactable  form  (instantiated).  When  this  enactable  process  is  sent  to  the  init.al  enactment  state  and 
a  Suitable  agent  is  provided,  an  enacting  process  can  be  initiated.  During  enactment,  the  control  process 
atohitors  performance  and  makes  appropriate  adjustments.  This  dynamic  control  phase  may  involve  ref¬ 
erence  to  ttie  process  plan,  the  process  definition,  and  the  process  trace. 
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3.1  Framework  for  Process  Definition 


This  section  defines  the  basic  process  artifacts.  The  next  section  introduces  terms  that  repre¬ 
sent  actions  on  these  objects.  For  example,  this  section  defines  process  designs  as  the  results 
of  designing  processes. 

The  structure  depicted  here  differs  somewhat  from  current  general  usage  in  the  process  com¬ 
munity.  Here,  we  have  chosen  to  establish  a  design  hierarchy  somewhat  analogous  to  that 
used  in  system  engineering.  With  systems,  one  starts  with  an  overall  architecture  and  pro¬ 
ceeds  to  a  design,  then  an  implementation,  and  then  to  an  operable  unit.  With  processes,  the 
flow  is  the  same  only  we  replace  the  term  implementation  with  process  definition  and  operable 
unit  with  enactable  process.  In  prior  process  parlance,  the  terms  process  program  and  pro¬ 
cess  model  have  been  used  more  or  less  interchangeably  to  refer  to  what  are  here  called  de¬ 
fined  processes.  This  new  terminology  is  introduced  because  we  found  that  more  precise 
terms  are  required.  The  terms  model  and  program  continue  to  be  used  in  a  form  that  is  closer 
to  traditional  usage  in  software  and  computer  science. 

Process  Architecture:  A  conceptual  framework  for  consistently 
incorporating,  relating,  and  tailoring  process  elements  into  enactable 
processes.  An  architecture  provides  a  space  of  process  designs.  A  process 
architecture  is  often  needed  when  a  process  must  relate  to  other  existing  or 
future  processes.  Examples  of  such  needs  are  process  element  reuse, 
process  enhancement,  and  process  tailoring.  An  essential  property  of  a 
process  architecture  is  its  ability  to  indicate  whether  a  process  element  is  or 
is  not  compatible  with  the  architecture. 

Process  Design  (noun):  An  embodiment  of  a  process  architecture  that 
establishes  the  architectural  options  and  parameters,  the  existing  elements 
to  be  reused,  the  structure  and  behavior  of  the  new  elements,  and  the 
relationships  among  these  elements.  A  pi-ocess  design  may  be  for  a  specific 
project,  an  entire  organization,  or  possibly  for  larger  classes  of  projects  or 
organizations.  A  process  design  is  produced  to  meet  specified  goals.  The 
completed  design  includes  the  process  definition  and  instantiation  standards 
and  interfaces,  the  overall  process  structure,  and  the  functions  and 
relationships  of  the  process  elements.  This  may  include  reusable  process 
definitions  and  partially  or  fully  populated  process  elements.  The  design 
specifies  the  selection  choices  to  be  made  during  process  development. 

Process  Definition:  An  implementation  of  a  process  design  in  the  form  of  a 
partially  ordered  set  of  process  steps  that  is  enactable.  At  a  lower  level  of 
abstraction,  each  process  step  may  be  further  refined  into  more  detailed 
process  steps.  A  process  definition  may  consist  of  (sub)process  definitions 
that  can  be  enacted  concurrently.  Process  definitions  whose  levels  of 
abstraction  are  refined  fully  are  referred  to  as  complete  or  fit  for  enactment. 
Completeness,  however,  depends  on  context  since  a  definition  that  is 
complete  for  one  process  agent  may  not  be  for  another.  A  process  definition 
may  be  for  a  class  of  projects,  a  specific  project  team,  or  an  individual 
professional. 
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Process  Plan:  A  specification  of  the  resources  necessary  for  the  enactment 
of  a  process  definition,  the  relationships  of  these  resources  to  process  steps, 
the  products  produced  by  these  steps,  and  any  constraints  on  enactment  or 
resources.  Process  plans  guide  the  instantiation  and  use  of  processes  while 
project  plans  guide  the  design,  development,  evolution,  and  tailoring  of 
processes  (or  products).  Process  plans  are  created  with  respect  to  a  process 
definition  containing  process  steps  to  be  planned  and  managed.  Resources 
include  human  process  agents,  computer  resources,  time,  and  budgets. 
Relationships  refer  to  the  estimation  or  assignment  of  resources  to  process 
steps  in  order  to  meet  project  objectives.  The  more  common  term  of  project 
plan  typically  contains  work  packages,  i.e.,  a  process  definition  at  a  certain 
level  of  abstraction,  together  with  one  or  more  process  plans.  The  distinction 
between  the  project  plan  and  the  process  plan  is  important  because  effective 
project  planning  is  facilitated  by  the  existence  of  a  defined  process.  This  often 
requires  that  the  process  plan  be  established  and  Implemented  In  parallel 
with  or  even  before  the  project  plan.  Because  of  the  time  and  resources 
required,  the  process  design  and  development  must  be  done  in  advance  of 
the  project  need. 

Enactable  Process:  An  Instance  of  a  process  definition  that  Includes  all  the 
elements  required  for  enactment.  An  enactable  process  consists  of  a  process 
definition,  required  process  inputs,  assigned  enactment  agents  and 
resources,  an  initial  enactment  state,  an  initiation  agent,  and  continuation  and 
termination  capabilities.  A  process  that  lacks  any  of  these  conditions  Is  not 
enactable.  it  should  be  noted  that  while  enactable  processes  may  not  actually 
terminate,  at  least  for  long  periods,  they  must  have  a  termination  capability  so 
they  can  be  stopped  in  an  orderly  way  when  necessary. 

Process  Model:  An  abstract  representation  of  a  process  architecture, 
design,  or  definition.  Process  models  are  process  elements  at  the 
architectural,  design,  and  definitions  level,  whose  abstraction  captures  those 
aspects  of  a  process  relevant  to  the  modeling.  Any  representation  of  the 
process  is  a  process  model.  Process  models  are  used  where  use  of  the 
complete  process  Is  undosirable  or  impractical.  A  process  model  can  be 
analyzed,  validated,  and,  if  enactable,  it  can  simulate  the  modeled  process. 
Process  models  may  be  used  to  assist  in  process  analysis,  to  aid  In  process 
understanding,  or  to  predict  process  behavior. 

3.2  Engineering  of  Processes 

This  section  includes  discussions  of  concepts  related  to  the  engineering  of  processes.  The  en¬ 
gineering  of  a  process  is  a  process  that  itself  can  be  defined  and  engineered. 

Development:  The  act  of  creating  enactable  processes.  It  may  Include 
planning,  architecture,  design.  Instantiation,  and  validation.  If  the  process 
development  activity  is  for  a  complete  process,  all  or  most  of  these  activities 
should  be  conducted.  If,  however,  the  development  effort  Is  to  repair  or 
enhance  an  existing  process,  an  abbreviated  set  of  activities  might  bo  used, 
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Tailoring;  The  act  of  adapting  process  designs  and  process  definitions  to 
support  the  enactment  of  a  process  for  a  particular  purpose.  Procees  tailoring 
may  Involve  the  uie  of  procees  templatos  and  may  result  in  specialized 
process  definitions. 

PU-nnlng;  The  act  of  developing  a  process  plan  for  the  enactment  of  a 
process  definition.  Process  planning  should  typically  precede  process 
Instantiation  and  enactment,  if  the  process  being  planned,  for  example,  was 
process  development,  then  the  process  plan  would  be  part  of  the  process 
development  project  plan. 

Instantiation:  The  act  of  creating  enact  able  processes  from  process 
definitions  and  process  plans.  Process  Instantiation  may  bo  static  or  dynamic. 

In  static  Instantiation,  the  complete  process  definition  is  Instantiated  before 
enactment,  in  the  dynamic  case,  the  process  development,  the  instantiation 
of  Individual  stops  of  that  process,  and  the  enactment  of  these  steps  may  be 
Interleaved.  The  dynamic  case  permits  enactment  of  processes  to  be  started 
before  their  definition  Is  complete.  Process  instantiation  may  Involve  the 
packaging  of  various  process  options  and  tailorings  Into  o  set  of  process 
scripts  or  the  assignment  of  resources  to  planned  process  steps.  In  this  latter 
case.  Instantiation  must  be  accompanied  by  both  a  process  definition  and  a 
process  plan.  In  tome  cases.  It  may  be  desirable  to  simultaneously  plan 
multiple  Instantiations  to  reduce  the  amount  of  planning  and  Improve  the 
efficiency  of  Instantiation, 

Evolution;  The  act  of  changing  existing  process  definitions  to  meet  new 
needs.  Process  evolution  Is  typically  Intended  to  correct  Kno'wn  problems  or 
to  evolve  the  process  to  meet  new  needs.  Process  evolution  should  be 
planned  and  carefully  managed  to  Insure  the  continuing  integrity  and  quality 
of  the  resulting  products,  Process  definitions  may  evolve  without  affecting 
existing  enacting  Instances,  or  they  may  evolve  together  with  their  enacting 
Instances,  This  latter  case  Is  needed  for  non'Stop  or  long-running  processes. 

3.3  £nactmtnt  of  ProceoMt 

Ternir  dealing  with  enactment  of  processes  are  grouped  Into  four  subgroups;  Process  Enact- 
msrit,  Process  Control,  Pfooeie  Authority,  and  Process  Assurance,  Process  Enac'rnent  Intro- 
duens  terms  concerning  tfie  mechanics  of  enacting  a  process.  Process  Control  addresses  the 
monitoring,  analysis,  and  adjustment  of  a  process  to  direct  or  to  improve  Its  behavior.  The  Pro¬ 
cess  Authority  terms  deal  with  authorization,  appra'sal,  delegation,  and  intrusion.  Process  As¬ 
surance  deals  with  the  methods  of  adapting  a  process  definition  to  address  unexpected 
situations,  and  with  the  means  for  ensuring  proper  enactment  of  the  established  process  def¬ 
inition, 

Prooeee  Eneotment 

Agent;  An  entity  that  enacts  a  process  definition.  This  entity  may  bo  a  person 
following  a  process  script  or  a  machine  executing  a  process  program.  The 
process  agent  interprets  the  onactable  process. 
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Process  Constraint:  A  defined  condition  that  an  enacting  process  must 
satisfy.  Process  constraints  typically  relate  the  enacting  process  to  external 
processes  or  agents.  Examples  ot  process  constraints  are  product 
requirements,  authorizations,  standards,  and  procedures.  Such  constraints 
may  be  included  In  process  designs,  process  programs,  process  scripts, 
process  architectures,  or  process  plans. 

Enactment  State:  The  state  of  a  particular  enactable  process.  The 
enactment  state  consists  of: 

•  enactment  flow  pointers  that  refer  to  the  steps  in  the  process 
definition  currently  being  enacted 

•  state  information  reflecting  the  satisfaction  of  process  constraints 

•  the  satisfaction  record  of  conditions  and  dependencies 

•  current  resource  utilization  records 

•  the  status  of  the  work  products  being  produced 

The  process  enactment  state  is  changed  through  enactment  of  a  process 
step,  through  interaction  with  a  cooperating  process,  or  through  initiation, 
suspension,  resumption,  or  termination  by  a  controlling  process.  The 
specification  of  the  process  state  must  also  consider  the  states  of  other 
related  entities,  whether  precisely  defined  or  not.  Examples  of  such  related 
entities  are  the  process  plan,  the  associated  product,  the  project,  and  the 
organization.  The  process  enactment  state  is  associated  with  an  instance  of 
an  enactable  process.  The  enactable  process,  in  turn,  identifies  the  specific 
version  of  the  process  definition  being  enacted.  Since  the  process  steps  may 
have  various  levels  of  abstraction,  their  process  states  must  also  have 
equivalent  levels  of  abstraction. 

Enacting  Process:  An  active  enactable  process,  i.e.,  an  enactable  process 
whose  agent  or  agents  are  executing  the  process  definition.  An  enacting 
process  may  be  in  a  suspended  state  if  an  assigned  process  agent  is  not 
available  or  other  process  constraints  are  not  satisfied. 

Interaction:  The  Interchange  between  fw'o  cooperating  enactable  processes. 

This  Interchange  may  be  for  the  purpose  of  communication  (interchange  of 
data)  or  coordination  (interchange  of  control).  The  interchange  may  be 
synchronous  or  asynchronous,  and  its  state  data  may  be  accessible  or 
hidden.  That  is,  one  process  may  have  access  to  state  data  for  other 
processes  while  they  have  no  access  to  its  state  data.  Andrews  discusses  a 
set  of  process  interaction  paradigms  in  distributed  systems,  many  of  which 
can  also  be  applied  to  the  software  process  [Andrews  91). 

Automation:  The  use  of  machine  process  agents  in  process  enactment. 

Here,  the  use  of  a  machine  agent  is  facilitated  by  a  fully  developed  process 
definition  embodied  in  a  suitable  process  program. 

Process  Control 

Control  Process:  A  process  that  exists  separate  from  an  enacting  process, 
but  has  access  to  its  state  data  and  can  affect  its  enactment.  A  control 
process,  for  example,  may  initiate,  monitor,  adjust,  or  terminate  its  controlled 
process  or  processes.  The  form  of  process  control  is  a  key  process  design 
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decision.  It  may  be  fully  centralized  or  distributed.  In  the  distributed  case,  for 
example,  one  can  visualize  each  process  step  behaving  like  a  program 
procedure  that  invokes  other  steps.  This  \would  permit  the  design  of  recursive 
processes  where  steps  may  call  themselves. 

Monitoring;  The  observation  of  the  enactment  of  a  process.  Monitoring  is 
performed  by  a  separate  observer  or  control  process  that  monitors  the 
enactment  state  of  the  observed  process.  This  observation  is  performed 
concurrently  and  typically  with  minimum  interference  in  the  behavior  of  the 
process  being  observed.  Process  monitoring  may  be  performed  by  the  same 
process  agent  that  is  enacting  the  process  or  by  a  separate  agent.  The 
purpose  of  process  monitoring  is  to  gather  data  on  the  enactment  state  and 
process  resource  utilization.  This  data  is  then  used  to  provide  a  process 
measurement  database  for  use  in  process  planning,  analysis,  control,  and 
adjustment. 

Process  Trace:  A  sequence  of  snapshots  of  the  enactment  state  reflecting 
the  observed  enactment  history.  Tracing  is  one  means  of  monitoring  and 
measuring  a  process.  A  trace  may  be  of  resource  utilization,  enaction  time, 
error  occurrences,  or  any  other  desired  parameters. 

Analysis:  The  use  of  process  traces,  process  definitior.s,  and  process  plans 
to  assess  process  behavior.  Process  analysis  may  be  performed  to 
determine  if  an  enacting  process  is  conforming  to  proco.^'S  con?*' dints,  if  it  is 
meeting  plan  objectives,  or  if  process  plan  adjustments  or  process  definition 
changes  are  required.  Process  analysis  is  also  an  important  part  of  process 
evolution. 

Adjustment:  The  influence  of  a  control  process  over  the  enactment  of 
another  process.  This  influence  may  be  guided  by  analysis  of  observed 
process  data  and  exercised  through  changes  to  the  process  enactment  state, 
through  reassignment  of  resources,  or  through  changes  to  the  process 
definition. 
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Process  Authority 

Approval;  The  granting  of  the  right  to  enact  a  planned  process  or  process 
step.  Approval  is  given  in  accordance  with  the  established  process  definition 
and  process  plan  by  an  authorized  process  agent.  Lack  of  approval  from  a 
designated  responsible  authority  (controlling  process)  constitutes  a  violation 
of  process  constraints.  For  example,  Mr.  Jones  rnay  approve  a  specific 
process  change.  His  signature  is  the  approval. 

Authorization:  The  granting  of  the  right  to  give  approval.  The  establishment 
of  explicit  authorities  and  responsibilities  is  an  essential  part  of  process 
planning  and  instantiation.  For  example,  Mrs.  Smith  authorizes  Mr.  Jones  to 
approve  process  changes. 

Delegation:  The  authorizing  of  other  agents  to  enact  process  steps  that  the 
delegating  process  (agent)  Is  authorized  to  perform.  Delegation  possibly 
involves  refinement  of  the  process  definition  before  the  responsibility  to  enact 
is  transferred.  For  exampie,  Mr,  Jones  may  delegate  his  approval  authority  to 
Ms.  Doe. 

Intrusion:  Unauthorized  process  monitoring,  adjustment,  or  repair.  One 
example  of  intrusion  could  be  a  case  where  a  project-specific  tailoring 
improperly  changes  the  baseline  process. 

Process  Assurance 

The  first  two  terms  assure  correct  enactment  by  modifying  the  enacting  process,  while  the  sec¬ 
ond  two  items  refer  to  activities  that  focus  on  assuring  that  the  process  enactment  follows  the 
process  definition. 

Repair;  The  temporary  correction  or  adjustment  of  a  non-conforming  process 
to  meet  an  Immediate  need.  Repairs  are  typically  required  when  there  Is 
insufficient  time  for  process  evolution  or  when  the  adjustment  is  a  unique 
event.  Process  repair  actions  may  result  In  process  improvement  proposals 
for  process  evolution. 

Recovery:  The  adjustments  required  to  allow  continuing  enactment  after  a 
process  Incident.  Process  incidents  may  result  from  a  process  Intrusion,  the 
occurrence  of  an  event  that  was  not  anticipated  by  the  process  definition,  or 
a  process  definition  defect. 

Enforcement:  The  activities  used  to  Insure  that  process  enactment  conforms 
to  process  constraints.  Enforcement  may  or  may  not  be  effective,  depending 
on  the  capabilities  of  the  process  agent  and  the  enforcement  methods  used. 

This  is  particularly  the  case  with  human  process  agents.  Enforcement  may 
also  include  the  initiation  of  (possibly  predefined)  consequences  In  case  of 
constraint  violation. 

Guidance:  The  activity  of  providing  the  enacting  process  agent  with 
assistance  regarding  the  legal  steps  at  any  point  during  process  enactment. 
Guidance  may  be  provided  by  a  control  process  and  may  involve  process 
cues,  process  Interaction,  or  process  management. 
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3.4  Process  Properties 

The  process  property  terms  relate  to  the  properties  of  entire  processes  as  well  as  to  the 
properties  of  their  elements.  The  process  property  terms  are  divided  into  two  categories, 
static  and  dynamic.  Static  properties  concern  the  characteristics  of  process  definitions, 
enactable  process,  and  process  results.  The  dynamic  properties  concern  the  enactment 
behavior  of  processes. 

Static  Process  Properties 

Accuracy:  The  degree  to  which  the  product  produced  by  the  process 
matches  the  Intended  result.  Note  that  neither  the  product  produced  by  an 
accurate  process  nor  the  product  intended  by  that  process  may  match  the 
actual  need. 

Fidelity:  The  faithfulness  with  which  a  defined  process  is  followed.  Fidelity 
concerns  the  degree  with  which  the  human  or  machine  agents  performing  the 
process  exactly  follow  the  defined  actions.  Fidelity  is  reiated  to  enforcement. 
Effective  enforcement  guarantees  high  levels  of  fidelity,  although  high  levels 
of  fidelity  may  occur  without  stringent  enforcement. 

Fitness:  The  degree  to  which  the  people  or  machines  enacting  the  process 
can  faithfully  follow  actions  It  specifies.  A  fit  process  definition  is  thus 
designed  so  the  enacting  process  agent  can  faithfully  follow  it,  while  an  unfit 
process  definition  may  be  so  poorly  represented  as  to  be  impractical, 
Inconvenient,  or  unintelligible.  Note  that  process  fitness  may  be  achieved 
through  other  means  than  process  design  and  definition.  Examples  are 
training  and  technical  support. 

Precision;  The  degree  to  which  the  process  definition  specifies  all  the 
actions  needed  to  produce  accurate  results.  That  is,  a  precisely  defined 
process  executed  with  fideilty  produces  an  accurate  result. 

Redundancy:  A  process  step  Is  redundant  If  Its  removal  would  not  alter  the 
results  of  the  process,  given  that  the  process  Is  executed  with  fideilty. 
Redundancy  may  be  added  to  compensate  for  human  or  other  errors  in 
process  enactment,  i.e,,  low  process  fidelity. 

Scalability:  The  breadth  of  activities  for  which  the  process  definition  Is 
designed.  This  might  inciude  the  ranges  in  numbers  of  people,  size  of 
product,  time  duration,  product  life  cycle,  or  development  environment  for 
which  the  process  is  fit  and  precise.  A  highly  scalable  process  is  thus  likely  to 
bo  of  more  general  value  than  one  that  is  less  scalable. 

Maintainability:  The  degree  to  which  the  process  Is  designed  to  readily 
permit  static  or  dynamic  process  evolution.  Maintainability  is  achieved 
through  localization  of  information,  a  cleanly  structured  design,  and  well 
architected  interfaces.  The  purpose  of  such  design  approaches  is  to  limit  the 
Impact  of  process  changes  and  thus  simplify  the  process  change  process. 
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Dynamic  Process  Properties 

Dynamic  process  properties  concern  the  singular  behavior  of  a  process  and  the  nature  of  its 
interactions  with  other  processes.  The  first  three  properties  concern  singular  process  behav¬ 
ior.  while  the  latter  two  deal  with  the  relationships  among  processes. 

Lifeness:  The  degree  to  which  an  enacting  process  that  contains  concurrent 
interacting  sub-processes  deals  with  deadlock,  starvation,  and  termination. 

The  degree  of  lifeness  indicates  whether  a  process  is  intended  to  terminate 
and  does  terminate,  or  whether  it  is  intended  not  to  stop  and  does  not  stop. 
Deadlock  refers  to  the  situation  when  two  or  more  interacting  processes  wait 
for  each  other.  Starvation  results  from  improper  process  design  or  from 
excessive  diversion  of  critical  enactment  resources,  not  i.llowing  the  process 
to  progress  according  to  plan. 

Robustness;  The  degree  to  which  the  process  rejects  intrusion.  A  robust 
process,  for  example,  would  typically  be  maintained  under  configuration 
control,  thus  rejecting  unauthorized  changes  to  the  process  definition. 

Fault  Tolerance:  The  degree  to  which  the  process,  once  an  intrusion  has 
occurred,  either  continues  to  produce  accurate  results  or  recognizes  the 
inaccuracy  of  its  results  and  initiates  corrective  action.  Here,  for  example,  a 
disciplined  change  management  system  would  insure  that  project-specific 
changes  were  isolated  from  the  baseline  process. 

Autonomy:  The  degree  to  which  an  enacting  process  operates 
independently  of  other  processes.  The  degree  of  autonomy  indicates  the 
extent  to  which  the  process  and  all  its  sub-processes  are  independent  of 
other  processes. 

Responsiveness;  The  degree  to  which  an  enacting  process  proactively 
initiates  and  controls  other  processes,  or  reactively  responds  to  events  from 
other  processes.  A  highly  responsive  process  thus  may  be  highly  incremental 
and  frequently  in  an  enactable  condition  waiting  for  interactions  to  trigger 
further  enactment.  A  high  degree  of  responsiveness  may  entail  a  reduction  in 
resource  utilization  efficiency. 
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4  Domain-Specific  Use  of  Process  Concept 
Definitions 


The  following  are  some  examples  of  process  terms  in  several  domains  that  are  expressed  us¬ 
ing  this  core  set  of  terms.  The  purpose  of  these  examples  is  to  illustrate  the  use  of  the  core 
set  of  terms  for  defining  additional  process  terms  and  to  provide  some  concrete  examples  of 
these  concepts  and  definitions.  We  have  chosen  the  domains  of  project  management,  oper¬ 
ating  systems,  and  process  engineering. 

4.1  Project  Management  Domain 

Role:  The  responsibility  for  enacting  a  process  or  subprocess  definition.  An 
agent,  when  enacting  a  process,  is  referred  to  as  assuming  the  process  role. 

In  this  role,  the  agent  is  limited  to  the  set  of  operations  reflected  in  the  steps 
of  that  process.  These  operations  are  specified  in  the  script  for  a  human 
agent  or  in  the  program  for  a  machine  agent.  A  process  may  have  more  than 
one  participating  agent. 

Task:  A  process  step  typically  enacted  by  a  human,  requiring  process 
planning  and  control.  This  definition  describes  the  term  task  as  it  is  typically 
used  in  project  management  or  for  managing  employee  work  assignments. 

Contract:  A  formal  agreement  on  a  process  plan  and  a  set  of  process 
enactment  states  and  results.  This  agreement  constitutes  a  process 
constraint,  whose  violation  has  (possibly  legal)  consequences. 

Policy:  The  guiding  principles  for  process  development  and/or  enactment. 

They  often  result  in  process  constraints,  usually  at  a  high  level,  that  focus  on 
certain  aspects  of  a  process  and  influence  the  enactment  of  that  process. 

Project:  An  enactable  process  or  enacting  process,  whose  architecture  has 
control  processes  for  managing  the  project  and  enacting  processes  for 
performing  the  project  tasks.  A  project  could  be  to  develop  a  product  or  to 
develop  a  process  definition. 

Project  Management:  An  enactable  or  enacting  process  whose  goal  is  to 
create  project  plans  and,  when  authorized,  instantiate  them,  monitor  them, 
and  control  their  enactment.  These  responsibilities  are  commonly  known  as 
project  planning,  project  control,  and  process  control.  When  properly 
performed,  the  project  management  function  is  typically  highly  interactive  in 
reviewing  and  approving  process  plans,  in  using  process  analysis  results, 
and  in  making  process  adjustments. 

Project  Plan:  The  project  plan  consists  of  a  process  definition  at  a  level  of 
abstraction  such  that  its  process  steps  have  to  be  managed  in  the  context  of 
one  or  more  plans  (i.e.,  resources,  responsibilities,  and  schedules).  When 
engineering  of  the  process  is  involved,  project  plans  should  explicitly 
incorporate  appropriate  process  plans. 
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Project  Manager;  A  human  agent  with  overall  responsibility  for  enacting  the 
control  process.  With  a  properly  designed  process,  this  includes  all  aspects 
of  controlling  and  managing  project  execution.  Project  managers  are  also 
frequently  involved  in  such  related  activities  as  requirements  determination, 
goal  setting,  resource  allocation,  contract  negotiation,  systems  partitioning, 
coordination,  and  post  contract  evaluation. 

4.2  Operating  System  Domain 

In  an  ACM  Computing  Sun/eys  article.  Horning  and  Randall  have  surveyed  and  discussed  op¬ 
erating  systems  concepts  as  they  relate  to  process  support  (Horning  73].  The  terms  used  by 
the  authors  reflect  the  vocabulary  used  by  the  research  community  at  the  time.  The  table  in 
Figure  4-1  lists  some  of  the  most  prevalent  terms  and  relates  them  to  the  definitions  in  this 
paper.  The  reader  may  also  notice  that,  in  the  context  of  operating  systems,  there  is  less  em¬ 
phasis  on  a  priori  planning,  while  increased  emphasis  is  placed  on  dynamic  scheduling  and 
different  forms  of  process  interaction.  The  terms  abstraction  and  refinement  have  been  implic¬ 
itly  introduced  in  the  context  of  the  definition  of  process  steps  in  this  paper,  while  they  have 
been  spelled  out  explicitly  by  Horning  and  Randall. 

4.3  Process  Engineering  Domain 

This  domain  concerns  the  process  for  developing  processes.  Such  a  process  development 
process  can  be  developed,  tailored,  planned,  instantiated,  evolved,  and  enacted.  Further, 
since  large  organizations  would  generally  need  many  different  kinds  of  processes  and  since 
many  of  these  processes  will  be  of  different  magnitudes  and  in  different  evolutionary  stages, 
the  organization  would  also  generally  need  more  than  one  process  development  process.  This 
process  family,  or  system  of  process  development  processes,  would  likely  include  a  process 
architecture,  a  library  of  reusable  process  definitions,  and  various  standards,  templates,  and 
forms. 

The  process  architecture  would  relate  all  members  of  this  process  family.  It  might  have  the 
following  sections: 

•  definitions  of  the  major  process  elements  and  their  functions 

•  naming  conventions  and  standards 

•  standard  process  templates  or  formats 

•  interface  specifications 

•  composition  and  tailoring  rules 

The  library  of  reusable  process  elements  would  be  used  as  common  building  blocks  to  con¬ 
struct  multiple  process  definitions.  These  reusable  elements  would  be  developed  consistently 
with  the  architecture  and  would  be  usable  with  any  process  definition  that  met  the  same  stan¬ 
dards.  Some  examples  of  such  reusable  elements  are  Process  Development  Planning.  Pro¬ 
cess  Requirements  Definition,  and  Process  Development  Estimation.  This  last  example  would 
be  one  of  the  lower  level  reusable  elements  referenced  by  Process  Development  Planning 
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Examples  of  the  standards  needed  by  the  process  development  process  are  Process  Review 
Standards,  Process  Requirements  Standards,  and  Process  Naming  Standards.  Typical  tem¬ 
plates  would  show  the  formats  for  process  development  plans,  the  contents  of  a  process  de¬ 
velopment  estimate,  and  the  structure  and  format  for  a  process  development  architecture. 


Typical  forms  would  be  the  Process  Development  Estimate  and  the  Process  Improvement 
Proposal. 


Operating  system  term 

Process  concept 

Explanation 

Process 

Process 

. 

Process  abstraction 

Not  explicitly  defined 

A  process  step  in  form  of  sub¬ 
routine  or  process  embodying 
the  abstraction 

Process  refinement 

Not  explicitly  defined 

The  act  of  defining  the  substruc¬ 
ture  of  a  process  step 

Process  state 

Enactment  state 

State  of  execution  of  a  process 

Computation 

Piocess  trace 

Processor,  machine 

Agent 

Typically  refers  to  machine 
agent 

Exact  realization 

Precision 

Process  interaction 

Interaction 

Three  forms:  cooperation,  com¬ 
petition,  interference 

Interpretation 

Enactment 

Image 

Enactable  process 

Executable  load  image  of  a  pro¬ 
gram 

Program 

Process  definition 

Language  description 

Not  explicitly  defined 

Notation  to  express  process 
definition 

Executive 

Control  process  giving 
approval  for  enactment 

Focus  on  adjustment  of  enact¬ 
ment  state 

Debugger 

Control  process 
performing  repair 

Focus  on  monitoring,  analysis, 
and  adjustment  of  enactment 
with  respect  to  desired  behav¬ 
ior  of  process  definition 

Figure  4*1  Process  Term  Sample  In  the  Operating  System  Domain 
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Examples  of  end-user  process  development  scripts  are  the  following; 

1.  The  process  for  developing  a  new  family  of  processes  would  include  a  pro¬ 
cess  architecture,  a  reusable  element  library,  and  end-user  8crl[  ^ts.  An  exam¬ 
ple  of  such  a  process  family  would  be  the  complete  sot  of  software  develop¬ 
ment  and  maintenance  processes  needed  by  a  largo  software  organization, 

2.  The  process  for  developing  a  new  end-user  script  that  conformed  to  an 
existing  process  architecture  would  Include  new  scripts  and  possibly  some 
new  or  modified  reusable  process  elements.  An  example  of  such  a  process 
might  be  the  maintenance  and  support  process  for  a  newly  developed 
software  product. 

3.  The  process  for  enhancing  an  existing  process  definition  to  meet  some  now 
need  would  likely  include  modifications  to  the  existing  process  script  with 
possibly  some  new  reusable  element  definitions  or  modifications.  An 
example  of  such  a  process  enhancement  would  be  the  modification  of  a 
software  development  process  to  conform  to  a  newly  dofinod  customer 
acceptance  testing  requirement,  in  the  case  of  more  substantial  process 
modifications,  changes  or  additions  to  the  process  architecture  might  bo 
needed  as  well. 
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5  Conclusions 


This  cort  Mt  of  proceii  detinitloni  and  concepts  is  intended  both  to  facilitato  the  broader  ap¬ 
plication  of  these  concepts  in  the  software  community  and  to  serve  as  a  foundation  for  further 
definitional  work,  Since  software  process  technology  Is  In  an  early  state  of  development,  it  is 
•ssumod  that  these  core  terms  will  undergo  evolutionary  change  and  that  many  more  terms 
will  be  added,  it  Is,  however,  hoped  that  this  core  set  will  be  sufficient  to  facilitate  communica¬ 
tion  on  the  eoftware  process  and  various  process  related  domains. 

The  development  of  these  definitions  has  been  a  surprisingly  rewarding  process.  Not  only  has 
the  work  of  listing  and  defining  these  core  concepts  and  terms  clarified  and  sharpened  our 
views,  but  we  have  learned  a  great  deal  from  Interacting  with  many  of  our  associates.  We  have 
also  found  that  there  Is  enormous  Interest  In  this  subject.  Software  process  technology  is  new 
and  developing  rapidly,  and  is  just  beginning  to  be  structured  and  codified.  It  is  an  important 
and  useful  field  for  practitioners,  and  it  is  a  rich  and  largely  unexplored  field  for  research. 

As  we  delve  into  this  subject,  it  is  clear  that  there  is  a  richness  and  substance  to  the  technology 
that  Is  barely  discernible  on  the  surface,  in  principle,  we  are  talking  about  the  design  of  pro- 
coises  that  will  permit  fallible  humans,  with  the  aid  of  machines,  to  produce  infallible  products. 
To  do  this  economically  and  to  responsively  meet  society  s  needs  Is  a  challenge  of  the  first 
order.  The  challenge  of  software  process  research  Is  thus  to  find  economic  and  effective  ways 
to  t'ave  many  people  cooperatively  perform  complex  and  precise  intellectual  lasks.  Success 
will  bo  measured  both  by  tho  effectiveness  with  which  these  processes  meet  users'  needs  and 
by  tho  degree  to  which  they  contribute  to  making  software  engineering  a  rewarding  and  fulfill¬ 
ing  profession.  As  this  field  evolves,  the  technology  It  develops  will  undoubtedly  be  of  value  to 
many  other  human  activities, 
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Table  1 1ndex  of  Process  Definitions 
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Term 

Term 

Accuracy 

16 

Planning 

12 

Adjustment 

14 

Precision 

16 

Agent 

12 

Process 

7 

Analysis 

14 

Process  Architecture 

10 

Approval 

15 

Process  Assurance 

15 

Authorization 

15 

Process  Authority 

15 

Automation 

13 

Process  Constraint 

13 

Autonomy 

17 

Process  Control 

14 

Control  Process 

14 

Process  Design 

10 

Delegation 

15 

Process  Definition 

10 

Development 

11 

Process  Element 

7 

Enactable  Process  1 1 

Process  Enactment 

12 

Enacting  Process 

13 

Process  Model 

11 

Enactment  State 

13 

Process  Plan 

11 

Enforcement 

15 

Process  Program 

7 

Evolution 

12 

Process  Script 

7 

Fault  Tolerance 

17 

Process  Step 

7 

Fidelity 

16 

Process  Trace 

14 

Fitness 

16 

Recovery 

16 

Guidance 

15 

Redundancy 

16 

Instantiation 

12 

Repair 

15 

Interaction 

13 

Responsiveness 

17 

Intrusion 

15 

Robustness 

17 

Lifeness 

17 

Scalability 

16 

Maintainability 

16 

Tailoring 

12 

Monitoring 

14 
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The  scientific  treatment  of  the  software  process  is  relatively  new  and,  as  with  any  new  field,  the  initial  terminol¬ 
ogy  is  often  confusing.  When  terms  can  have  a  diversity  of  meanings,  technical  communication  is  more  difficult 
and  technological  progress  is  constrained.  This  paper  defines  a  core  set  of  concepts  about  the  software  pro¬ 
cess.  These  concepts  are  intended  to  facilitate  communications  and  to  provide  a  framework  for  further  defini¬ 
tions.  The  definitions  focus  on  essential  concepts;  however,  they  do  not  represent  a  comprehensive  glossary 
of  common  software  process  terms.  Following  an  initial  overview,  tnis  paper  outlines  the  basic  process  con¬ 
cepts  which  underlie  the  definitions.  The  definitions  are  then  grouped  in  four  sets:  a  framework  for  process 
definition,  an  engineering  of  process,  an  enactment  of  process,  and  process  properties.  This  is  followed  by 
illustrations  of  the  use  of  these  concepts  in  several  domains.  The  paper  concludes  with  some  observations  on 
the  definition  process. 
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